Remarks 



Entry of the amendments, reconsideration of the application, as amended, and allowance 
of all pending claims are respectfully requested. Claims 1-48 remain pending. 

With the above amendments, applicants are more particularly pointing out and distinctly 
claiming the data repository of one aspect of applicants' invention, as well as the locking. 
Support for this amendment can be found throughout the specification (FIGs. 4 and 5, and pages 
7-12 of the specification). Thus, no new matter is being added. 

In the Office Action, dated April 21, 2004, claims 1, 4 and 7 are rejected under 35 U.S.C. 
102(b) as being anticipated by NEC Corporation (JP 07200321 A); claims 1-10, 21-23, 34, 35, 
36, 47 and 48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Soltis et al. (U.S. 
Patent No. 6,493,804) in view of Huber (U.S. Patent No. 5,802,514); claims 11-14, 24-27 and 
37-40 are rejected under 35 U.S.C. 103(a) as being unpatentable over Soltis in view of Huber 
and further in view of Shaughnessy (U.S. Patent No. 5,555,388); and claims 15-20, 28-33 an 41- 
46 are rejected under 35 U.S.C. 103(a) as being unpatentable over Soltis in view of Huber and 
further in view of Annevelink (U.S. Patent No. 5,448,727). Applicants respectfully, but most 
strenuously, traverse these rejections to any extent deemed applicable to the amended claims. 

In one aspect, applicants' invention is directed to the efficient locking of resources of a 
global data repository. A locking facility is provided that enables concurrent access to a complex 
data structure, while minimizing the lock acquisition necessary to access a particular resource of 
that complex data structure. As one example, the complex data structure is a data repository that 
includes a plurality of resources (e.g., tables, directories). The repository has a hierarchical 
topology, and there are various relationships among the resources of the repository and the locks 
of the repository. As examples, the relationships of the resources may include containment- 
based relationships and reference-based relationships. 

One example of such a repository is depicted in FIG. 4 and reproduced below for the 
Examiner's convenience. 
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The type of locking relationship that exists depends on the particular relationship between 
the resources. For example, if the relationship between the resources is a containment-based 
relationship, then the locking acquisition is referred to as chained locking. On the other hand, if 
the relationship is a reference-based relationship, then the locking acquisition is referred to as a 
reference-based locking strategy. 

To minimize the locking needed, the locking strategy selected for a particular resource 
depends on the relationship between that resource and at least one other resource. For example, 
if Table A is to be locked, and since Table A has a containment-based relationship, a chained 
locking acquisition is used. In contrast, if Table B is to be locked, and since Table B has a 
reference-based relationship, then a reference-based locking strategy is used, as one example. 

In one particular embodiment, applicants claim a method of managing the locking of 
resources of a data repository (e.g., independent claim 1). The method includes, for instance, 
determining whether a relationship between one resource and another resource of a data 
repository is a containment-based relationship or whether the relationship is a reference-based 
relationship, wherein the data repository comprises a hierarchical structure of a plurality of 
resources, the hierarchical structure comprising one or more resources having a reference-based 
relationship and one or more resources having a containment-based relationship; and locking at 
least one resource of the plurality of resources using a locking strategy that depends on whether 
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the determined relationship is a containment-based relationship or a reference-based relationship. 
Thus, in one aspect of applicants' claimed invention, a determination is made as to the 
relationship of a resource, and based on whether that relationship is a containment-based or 
reference-based relationship, a locking strategy is employed. This is very different from the 
teachings of the references, either alone or in combination. 

For example, claims 1, 4 and 7 are rejected as being anticipated by NEC. However, 
applicants respectfully submit that there is no description, teaching or suggestion in NEC of 
determining whether a relationship between one resource and another resource is a containment- 
based relationship or whether the relationship is a reference-based relationship. Further, there is 
no description, teaching or suggestion in NEC of locking a resource using a locking strategy that 
depends on whether the determined relationship is a containment-based relationship or a 
reference-based relationship. 

The NEC Abstract merely states that resources have a relationship and that a resource 
may be locked. There is no correlation between the type of relationship and the locking strategy 
used in NEC. Further, NEC does not make reference to different types of relationships nor does 
it describe applicants' claimed data repository that has a hierarchical structure of a plurality of 
resources in which one or more resources have a containment-based relationship and one or more 
resources have a reference-based relationship. There is no such discussion in the Abstract. 

Since NEC fails to describe, teach or suggest at least one of: applicants' claimed data 
repository; the hierarchical structure of the data repository in which one or more of the resources 
have a reference-based relationship and one or more of the resources have a containment-based 
relationship; different types of relationships; and locking a resource using a locking strategy that 
depends on the type of relationship, NEC does not anticipate applicants' claimed invention. 
Therefore, applicants respectfully request withdrawal of the Section 102 rejection based on NEC. 

In addition to the above, claims 1-10, 21-23, 34-36 and 47-48 are rejected as being 
unpatentable over Soltis in view of Huber. However, applicants respectfully submit that there is 
no teaching or suggestion in Soltis or Huber, either alone or in combination, of one or more 
aspects of applicants' claimed invention. 
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For instance, Soltis fails to describe, teach or suggest determining whether a relationship 
between one resource and another resource of a data repository is a containment-based 
relationship or whether the relationship is a reference-based relationship, wherein the data 
repository comprises a hierarchical structure of a plurality of resources, said hierarchical 
structure comprising one or more resources having a reference-based relationship and one or 
more resources having a containment-based relationship. Soltis fails to mention different types 
of relationships and does not differentiate between different types of relationships. There is no 
discussion in Soltis of whether a relationship is a containment-based relationship or a reference- 
based relationship. This just is not discussed. Thus, Soltis does not make any determination as 
to the type of relationship. 

Since Soltis fails to teach or suggest determining whether a resource has a containment- 
based relationship or a reference-based relationship, it follows that Soltis does not teach or 
suggest locking the resource using a locking strategy that depends on whether the determined 
relationship is a containment-based relationship or a reference-based relationship. There is no 
analysis in Soltis of determining the type of relationship of a resource to be locked (i.e., whether 
it is containment-based or whether it is reference-based), and then selecting the locking strategy 
based on that determination. This is simply missing from Soltis. Soltis does not even mention 
containment-based relationships or reference-based relationships, much less make any decisions 
based on such relationships. Thus, applicants respectfully submit that Soltis does not teach or 
suggest one or more aspects of applicants' claimed invention. 

It is even admitted in the Office Action that Soltis does not disclose the step of 
determining a relationship between the resources. Since Soltis does not determine whether a 
resource has a containment-based relationship or whether the resource has a reference-based 
relationship, it follows that Soltis does not lock the resource using a locking strategy that 
depends on the determined relationship. Due to the deficiencies of Soltis, Huber is combined 
with Soltis. However, Huber does not overcome the deficiencies of Soltis. 

Huber describes an automated client/server development tool using drag and drop 
metaphor. Huber describes the storing in a repository a description of the server database 
describing database entities within the server database and relationships between those database 
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entities (see Abstract). This information is used by a tool to develop a client portion of a 
multiple table, client/server database application. There is, however, no description, teaching or 
suggestion in Huber of locking. Further, there is no description, teaching or suggestion of 
applicants' claimed element of locking at least one resource of a plurality of resources using a 
locking strategy that depends on whether a determined relationship is a containment-based 
relationship or a reference-based relationship. Huber only describes relationships in terms of 
automatically building an application. There is no teaching or suggestion of locking a resource 
using a locking strategy that depends upon whether the determined relationship is a containment- 
based relationship or a reference-based relationship. Again, there is no locking at all in Huber. 
Thus, Huber fails to teach or suggest at least applicants' claimed locking element. 

Since both Huber and Soltis fail to teach or suggest at least applicants' claimed element 
of locking a resource using a locking strategy that depends on whether the relationship of the 
resource is containment-based or reference-based, applicants respectfully submit the combination 
of Soltis and Huber also fails to teach or suggest this claimed element. 

Moreover, there is no teaching or suggestion in the references themselves as to why one 
would combine Soltis with Huber. Applicants respectfully submit that one skilled in the art 
looking to manage the locking of references would not consult Huber, since Huber is not at all 
concerned with locking. Thus, applicants respectfully submit that the combination is improper. 

Based on the foregoing, applicants respectfully submit that independent claim 1, as well 
as the other independent claims are patentable over the cited references, either alone or 
combined. Moreover, the dependent claims are patentable for the same reasons as the 
independent claims, as well as for their own additional features. Applicants respectfully submit 
that neither Shaughnessy nor Annevelink overcome the deficiencies of Soltis or Huber, either 
alone or in combination. For example, neither Shaughnessy nor Annevelink describe, teach or 
suggest applicants' claimed determining whether a relationship between one resource and 
another resource of a data repository is a containment-based relationship or whether the 
relationship is a reference-based relationship and then locking that resource based on whether the 
determined relationship is a containment-based relationship or a reference-based relationship. 
This is not taught or suggested in Shaughnessy or Annevelink. 
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As one particular example, Shaughnessy is cited as teaching the aspects claimed in 
applicants' claim 11. Claim 1 1 recites wherein the relationship is a containment-based 
relationship, wherein the at least one resource comprises a first resource and a second resource, 
the first resource referencing the second resource and wherein the locking comprises write 
locking the first resource in order to create an instance of the second resource. Applicants 
respectfully disagree that this is taught in Shaughnessy. The Office Action cites Col. 9, line 44- 
Col. 10, line 37 for this teaching. However, a careful reading of that section merely indicates the 
difference between a full lock and a write lock. There is no teaching or suggestion of write 
locking a first resource in order to create an instance of a second resource. This is simply 
missing from Shaughnessy. Thus, applicants respectfully submit that claim 1 1 is patentable over 
the combination of Soltis, Huber and Shaughnessy. 

The other dependent claims are patentable over the references for similar reasons, as well 
as for their own additional features. Again, neither Shaughnessy nor Annevelink overcome the 
deficiencies of Solits and Huber. While Shaughnessy and Annevelink may discuss locking in 
terms of exclusive locking and shared locking, there is no description, teaching or suggestion in 
any of the references of determining whether the relationship between one resource and another 
resource of a data depository is a containment-based relationship or whether the relationship is a 
reference-based relationship, and then locking the resource using a locking strategy that depends 
on whether the relationship is a containment-based relationship or a reference-based relationship. 
Since at least this aspect of applicants' claimed invention is missing from all of the references, 
applicants respectfully request an indication of allowability of all pending claims. 
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Should the Examiner wish to discuss this case with applicants' attorney, please contact 
applicants' attorney at the below listed number. 



Respectfully submitted, 



Blanche E. Schiller 
Attorney for Applicants 
Registration No.: 35,670 

Dated: August 3X>, 2004. 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 

Albany, New York 12203-5160 

Telephone: (518)452-5600 

Facsimile: (518)452-5579 
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